IReactiveProgramming (IRP)

分散型グラフデータベースの開発が進む中、BartとSavasは、グラフにリアクティブなコンポーネントを追加するというアイデアを検討し始めました。クラウド・プログラマビリティ・チーム時代の「チャット・サーバー」のデモや、プロジェクト「デトロイト」の基本的なアイデアに触発され、Rxのサービス・レイヤーを構築するための初期設計作業が開始されました。その結果、"IReactiveProgramming "と呼ばれるプログラミングモデルが生まれました。IRPの目的は、リアクティブプログラミングシステムを正式な方法で記述し、「Reactive as a Service」（RaaS）を実現することです。

While the distributed graph database effort was ongoing, Bart and Savas started to entertain the idea to add a reactive component to the graph. Inspired by the “chat server” demo in the Cloud Programmability Teams days and the foundational ideas of project Detroit to a lesser extent, the initial design efforts on building a service layer for Rx were kicked off. This led to the creation of a programming model coined “IReactiveProgramming”, commonly abbreviated as IRP. The goal of IRP is to describe reactive programming systems in a formal manner, enabling “Reactive as a Service” (RaaS).

"IReactiveProgramming" は、インターフェイスであることを示すためにIで始まっていますが（.NETのネーミングガイドラインに準拠）、実際にはそのようなインターフェイスは存在しません。IRPのごく初期の設計や実装では、システム全体を1つのインターフェイスで表現しており、これがプロジェクト名の由来となっています。それ以来、この名前が定着しましたが、代わりに "IReactiveProcessing" と呼ぶ人もいます。この名前の痕跡は、今日、Reaqtorのコードベースを探ってみると見つかります。

Even though “IReactiveProgramming” starts with an I to designate it as an interface (conform .NET naming guidelines), no such interface really exists today. Very early designs and implementations of IRP described the whole system with a single interface, from which the project name was derived. The name stuck around ever since, with some referring to it as “IReactiveProcessing” instead. Traces of this name can be found when spelunking through the Reaqtor codebase today.

IRPの設計では、いくつかの点に着目しました。

The design of IRP focused on a number of aspects:

Rxでサポートされている式木をIQbservable<T>で拡張しています。特に、ObserverとSubjectの式表現も最低限必要でした。チャットサーバ」のデモでは、この点が明確に示されていました。

Extending on the expression tree support in Rx with IQbservable<T>. In particular, we also needed expression representations of observers and subjects, at the very least. The “chat server” demo made this omission clear.

非同期の疎結合クライアントのサポートにより、Task<T>ベースのAPIと、サブスクリプションやサブジェクト（ストリーム）などのリソースを識別する機能が必要になりました。

Support for asynchronous loosely connected clients, resulting in the need for a Task<T>-based API and the ability to identify resources such as subscriptions, subjects (streams), etc.

エンティティを表現するために使用されるデータモデルと、ARPのデザインの切り離し。例えば、IRPを「Bingデータモデル」、「CLRタイプシステム」、「Entity Framework」のいずれかに結合することは望ましくありません。

Decoupling of the data model used to represent entities and the design of IRP. For example, it’d be undesirable to couple IRP to either the “Bing data model”, the CLR type system, or Entity Framework, to name a few.

また、式木の正規化やシリアライズ機能を強化することで、クライアントとサービスの結合をさらに減らすことができます。グラフデータベースに取り組むことで、この分野における既存の技術の欠点が明らかになりました。

Further reducing the coupling between clients and services by focusing on better expression tree normalization and serialization capabilities. Work on the graph database helped to reveal shortcomings to existing art in this space.

IRPを、外部および内部の依存関係を最小限に抑えた小さなライブラリのセットとして構築することで、小さなデバイスから大規模なクラウドサービスまで、コアとなるIRPの実装を再利用できるようにしました。

Reusability of the core IRP implementation across tiny devices and massive cloud services by building IRP as a set of small libraries with minimal external and internal dependencies.

IRPの初期実装は、Bart De Smetが主に担当し、後にEric Rozellがチームに加わりました。

Initial implementation of IRP was largely done by Bart De Smet, with Eric Rozell joining the team later.